Motivation - see #2997. This is a PoC only! No intention to merge.

Reason for choosing Netsparkle over others: signature validation of update files (SSL these days doesn't mean a thing, and evilginx2 and friends are way too easy to use to fake update files)

Notes for using Netsparkle

Install dotnet tool for Netsparkle

dotnet tool install --global NetSparkleUpdater.Tools.AppCastGenerator

Create keys

netsparkle-generate-appcast --generate-keys --key-path ./signingkeys

Create appcast
netsparkle-generate-appcast -n "ILSpy" -a ./output -e msi -b ./ -o windows -f true -u https://github.com/icsharpcode/ILSpy/releases/tag/v8.0 --description-tag ".NET Decompiler" --key-path ./signingkeys --change-log-path ./

This assumes ILSpy_Installer_8.0.0.7400.msi and 8.0.0.7400.md (both files entirely fake) in the root folder where the command is run.

Notes for deploying the appcast

When you add release notes to the appcast, it will contain newlines, eg https://github.com/icsharpcode/ILSpy/blob/11a5bb50682fdf31c08a01e0937673ab6faa29a7/appcast.xml. When pushing from Windows and consuming as is the case here on Linux, you need appcast.xml eol=crlf in https://github.com/icsharpcode/ILSpy/blob/11a5bb50682fdf31c08a01e0937673ab6faa29a7/.gitattributes

Implementation notes

Comments included address a few of the edge cases found (and some not yet resolved). In general, if going down the route of #2997 we should have one update strategy for checking only, and one for auto-updating (think interface and two implementations that can be used depending on deployment variant)